
%% bare_jrnl.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% see http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE journal paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/



% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/


%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[journal]{IEEEtran}
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[journal]{../sty/IEEEtran}





% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.
\usepackage[backend=biber]{biblatex}
\bibliography{final_report}

% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
   \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/

\usepackage{listings}
\lstset{tabsize=4, basicstyle=\footnotesize\ttfamily}
\usepackage{courier}



% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.


%\ifCLASSOPTIONcaptionsoff
%  \usepackage[nomarkers]{endfloat}
% \let\MYoriglatexcaption\caption
% \renewcommand{\caption}[2][\relax]{\MYoriglatexcaption[#2]{#2}}
%\fi
% endfloat.sty was written by James Darrell McCauley and Jeff Goldberg.
% This package may be useful when used in conjunction with IEEEtran.cls'
% captionsoff option. Some IEEE journals/societies require that submissions
% have lists of figures/tables at the end of the paper and that
% figures/tables without any captions are placed on a page by themselves at
% the end of the document. If needed, the draftcls IEEEtran class option or
% \CLASSINPUTbaselinestretch interface can be used to increase the line
% spacing as well. Be sure and use the nomarkers option of endfloat to
% prevent endfloat from "marking" where the figures would have been placed
% in the text. The two hack lines of code above are a slight modification of
% that suggested by in the endfloat docs (section 8.3.1) to ensure that
% the full captions always appear in the list of figures/tables - even if
% the user used the short optional argument of \caption[]{}.
% IEEE papers do not typically make use of \caption[]'s optional argument,
% so this should not be an issue. A similar trick can be used to disable
% captions of packages such as subfig.sty that lack options to turn off
% the subcaptions:
% For subfig.sty:
% \let\MYorigsubfloat\subfloat
% \renewcommand{\subfloat}[2][\relax]{\MYorigsubfloat[]{#2}}
% For subfigure.sty:
% \let\MYorigsubfigure\subfigure
% \renewcommand{\subfigure}[2][\relax]{\MYorigsubfigure[]{#2}}
% However, the above trick will not work if both optional arguments of
% the \subfloat/subfig command are used. Furthermore, there needs to be a
% description of each subfigure *somewhere* and endfloat does not add
% subfigure captions to its list of figures. Thus, the best approach is to
% avoid the use of subfigure captions (many IEEE journals avoid them anyway)
% and instead reference/explain all the subfigures within the main caption.
% The latest version of endfloat.sty and its documentation can obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/endfloat/
%
% The IEEEtran \ifCLASSOPTIONcaptionsoff conditional can also be used
% later in the document, say, to conditionally put the References on a 
% page by themselves.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Research Project Final Report:\\Interconnection Network Block Cipher}
%
%
% author names and IEEE memberships
% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
% a structure at a ~ so this keeps an author's name from being broken across
% two lines.
% use \thanks{} to gain access to the first footnote area
% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
% was not built to handle multiple paragraphs
%

\author{Robert~O'Brien, David~O'Donnell, and Tracy~Wolf\\
Department of Computer Science and Engineering\\
University of South Florida}% <-this % stops a space

% note the % following the last \IEEEmembership and also \thanks - 
% these prevent an unwanted space from occurring between the last author name
% and the end of the author line. i.e., if you had this:
% 
% \author{....lastname \thanks{...} \thanks{...} }
%                     ^------------^------------^----Do not want these spaces!
%
% a space would be appended to the last name and could cause every name on that
% line to be shifted left slightly. This is one of those "LaTeX things". For
% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
% "AB" then you have to do: "\textbf{A}\textbf{B}"
% \thanks is no different in this regard, so shield the last } of each \thanks
% that ends a line with a % and do not let a space in before the next \thanks.
% Spaces after \IEEEmembership other than the last one are OK (and needed) as
% you are supposed to have spaces between the names. For what it is worth,
% this is a minor point as most people would not even notice if the said evil
% space somehow managed to creep in.



% The paper headers
%\markboth{Journal of \LaTeX\ Class Files,~Vol.~6, No.~1, January~2007}%
%{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Journals}
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.
% 
% *** Note that you probably will NOT want to include the author's ***
% *** name in the headers of peer review papers.                   ***
% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
% you desire.




% If you want to put a publisher's ID mark on the page you can do it like
% this:
%\IEEEpubid{0000--0000/00\$00.00~\copyright~2007 IEEE}
% Remember, if you use this you must call \IEEEpubidadjcol in the second
% column for its text to clear the IEEEpubid mark.



% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
%\boldmath
As devices become smaller and the application of embedded systems becomes more diversified the need for enhanced encryption schemes become more and more a necessity to the industry. Our paper focuses on a theory that we propose that would allow hardware to offer a more enhanced level of encryption abilities to help insure the protection of sensitive design schema or integral data protection. We will take a look at our encryption scheme in terms of what it will offer to hardware design implementation that will insure protection and will add another level of security. Further, we will offer a method of design that will offer a real world proof of concept to the feasibility of our encryption scheme and offer various test cases to provide a snapshot of the level of performance we have achieved through our research.  We also will show how it will be possible to decrypt our cypher back to its original form. Once we have proved our theories are feasible and real world applicable we will provide an evaluation that expands further with a look at the test cases and the results we have achieved through these test cases. Finally, we will take a look at these results and offer a sound conclusion of our findings as well as look at any shortfalls within our design that with further research may be refined to offer better performance that our proposed proof of concept.
\end{abstract}
% IEEEtran.cls defaults to using nonbold math in the Abstract.
% This preserves the distinction between vectors and scalars. However,
% if the journal you are submitting to favors bold math in the abstract,
% then you can use LaTeX's standard command \boldmath at the very start
% of the abstract to achieve this. Many IEEE journals frown on math
% in the abstract anyway.

% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
Encryption, Substitution cipher, Caesar, Vigen\`{e}re, Interconnection network, Block cipher
\end{IEEEkeywords}


% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



%\section{Introduction}
% The very first letter is a 2 line initial drop letter followed
% by the rest of the first word in caps.
% 
% form to use if the first word consists of a single letter:
% \IEEEPARstart{A}{demo} file is ....
% 
% form to use if you need the single drop letter followed by
% normal text (unknown if ever used by IEEE):
% \IEEEPARstart{A}{}demo file is ....
% 
% Some journals put the first two words in caps:
% \IEEEPARstart{T}{his demo} file is ....
% 
% Here we have the typical use of a "T" for an initial drop letter
% and "HIS" in caps to complete the first word.
%\IEEEPARstart{T}{his} demo file is intended to serve as a ``starter file''
%for IEEE journal papers produced under \LaTeX\ using
%IEEEtran.cls version 1.7 and later.
% You must have at least 2 lines in the paragraph with the drop letter
% (should never be an issue)
%I wish you the best of success.

%\hfill mds
 
%\hfill January 11, 2007

%\subsection{Subsection Heading Here}
%Subsection text here.

% needed in second column of first page if using \IEEEpubid
%\IEEEpubidadjcol

%\subsubsection{Subsubsection Heading Here}
%Subsubsection text here.


% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals use top floats exclusively.
% Note that, LaTeX2e, unlike IEEE journals, places footnotes above bottom
% floats. This can be corrected via the \fnbelowfloat command of the
% stfloats package.

\section{Introduction}
\IEEEPARstart{I}{n this} document, we propose a new encryption scheme consisting of a combination of a substitution cipher and an interconnection network (ICN). We also will propose the reverse engineered ICN and substitution cipher to show that it will be possible to decrypt the final cipher but only with the matching decryption scheme.  This implementation is reminiscent of an Enigma machine. The basic concept of the system would be to have an input passed through substitution cipher and then sent through the ICN to transpose the input. So when a message is input into the system, the substitution cipher will initially scramble the text and then the ICN will take the ciphertext and transpose the characters in the message. Then the exact opposite would need to be done in order to decrypt the message, so without knowing the exact ICN and substitution cipher that was used it would be very difficult to decrypt the message since there will be no visual patterns to recognize. This system will be implemented in hardware. We will code the process using a hardware description language (HDL) to create the cipher and ICN, and then we will test the code on a behavioral as well as physical level using an FPGA board.

\subsection{Vigenere Cipher}
The Julius Caesar cipher is a type of substitution cipher that uses a simple shift to encrypt a plain text. Each letter of the English alphabet is assigned a position value (0-25) that is then shifted by a fixed number of positions, the key value, and substituted back into the text to create the ciphertext. We chose to use the Vigenere cipher because it is essentially a sequence of 26 different Caesar ciphers with every possible shift value to create a table where each row is it’s own alphabet sequence. A ciphertext is created by using the key value as the row index and the plain text as a column index. The alphabet found at the intersection is what is then used for the ciphertext \cite{modern_caesar_vigenere}. Thus a vigenere cipher is easy for us to implement with code because it is just one line that is constantly shifted to create a table but it is still much more complex than if we were to use a Caesar cipher. 

We also chose to use a Vigenere cipher because it works as a block cipher which is ideal for working with large chunks of data at a time. On other hand, if we wanted to encrypt only a single byte at a time then we would have preferred to use a streaming cipher. Some disadvantages to using the block cipher is that it is typically slower than a stream cipher and requires the use of more memory than a stream cipher since it works with larger chunks of data. However, stream ciphers are much more difficult to correctly implement compared to a block cipher and do not provide any integrity protection or authentication. Thus if our purpose was to encrypt an unknown amount of data we would have chosen a stream cipher for our project since stream ciphers work with infinite single inputs of data but since we are using known text file sizes,a block cipher is the  ideal choice with the pros of it’s usage for our needs outweighing the cons.

\subsection{Interconnection Network}
We expand on the use of the Vigenere cipher by passing the ciphertext created by the Vigenere table through an ICN to transpose the input and to create our final encryption scheme. An interconnection network, commonly referred to as an ICN, is a set of links between nodes that provides a path from one node to another. Interconnection networks are commonly used in computer networks for providing paths between nodes such as memory elements and processing elements. ICNs come in two types: static and dynamic.

Static interconnection networks, also known as direct networks, provide paths from one point to another but the topology is fixed. This means there may be a few paths from one node to another but the overall topology cannot be changed. Also, static ICNs provide point-to-point communication. The traffic, whether it is network data or simple messages, travel through other nodes before reaching the desired destination. A few examples of direct ICNs are the star, ring, mesh, and hypercube network topologies.

Dynamic interconnection networks, also referred to as indirect networks, are quite the opposite. The topology of a dynamic ICN is not fixed and can be changed dynamically. Traffic passes through one or more switches before reaching the destination. A simple example of a dynamic ICN is a crossbar network. Some node connections run horizontally while the others run vertically. Where these lines overlap are switches that can make or break the connection between the two lines. A connection made at any overlap means those two nodes are directly connected and can communicate.

Dynamic ICNs can also have multiple stages, putting these implementations in a class appropriately termed multistage interconnection networks. Here, the network is composed of the nodes and links as well as configurable switching elements, devices akin to simple switch boxes. The switching elements typically have four connections, two on either side. A switching element can have two states: straight-through or crossover. This means the inputs can either be connected to their respective output or the opposite output. If we have inputs A and B and outputs Y and Z, a straight-through configuration would tie A and B to Y and Z, respectively, with a crossover configuration connecting A and B to Z and Y, respectively. Pictorially, the nodes are placed on either side of the network. Between the nodes lie multiple switching elements with links directly connecting each node to exactly one connection point on one switching element. Each connection point on the switching element is also connected to exactly one point on another switching element (or a node). The connections between nodes are determined by the configuration of the switching elements between the nodes.

\section{Related Work}
Our interconnection network encryption scheme is similar to some related work on a modernization of the Julius Caesar and Vigenere ciphers because we also seek a way of using the Vigenere cipher to encrypt plaintext in a more complex way than the original simple substitution method so that it can not easily be decoded by recognizing patterns in the ciphertext.  Another alike paper presented makes use of the Neuron System and Feistel Network to make a much more complex and random block cipher algorithm much like our ICN is doing to the Vigenere cipher.

\subsection{A Modern Avatar of Julius Caesar and Vigen\`{e}re Cipher \cite{modern_caesar_vigenere}}
In this section, we study a way that simple substitution ciphers, such as Julius caesar and Vigenere ciphers, can be made more difficult to decrypt. They need to be made more difficult since the current power of computers makes these methods very weak and easily decoded. The ciphers are modernized by selecting a prime number and identifying its primitive roots and creating all the necessary generators for a chosen primitive root. The generator values become the key values for the ciphers and each positional value of the plain text is added with the corresponding key value and reduced by modulo 26 to create the new position for the cipher text. The cipher text can then be decoded by simply subtracting the key value and then applying the modulo 26 to get the plain text.

An example of how this method works is as follows. Suppose we choose the prime number 101. The primitive roots of 101 are 2, 3, 7, 8, 11, 12, 15, 18, 26, 27, 28, 29, 34, 35, 38, 40, 42, 46, 48, 50, 51, 53, 55, 59, 61, 66, 67, 72, 73, 74, 75, 83, 86, 89, 90, 93, 94, 98, and 99. So if the random base value 52 is selected we compute the generators by using the equation:
\begin{equation}
	51 = \bmod 101
\end{equation}
to create the new key values that are used as shift keys in the Caesar cipher. Thus a plaintext of

\begin{center}
	``MAN PROPOSES GOD DISPOSES''\\
	now becomes\\
	``IUS JPSCHCBB JWP KGKWDYSN''\\
\end{center}

This method makes it so even though the letter ``O'' is repeated throughout the plain text, the substitution letter that replaces each ``O'' in the ciphertext is different each time making it more difficult to decode without using the decryption formula
\begin{equation}
	M_i = (C_i-K_i) \bmod 26
\end{equation}
Thus the strength of this algorithm is defined by choosing the prime factor and its relevant primitive root. Even if an attacker has a pair of known cipher-text and its plain text it would be hard for the attacker to discover the key value as it is no longer a simple substitution value.

\subsection{A Novel Feedback Block Cipher Based on the Chaotic Time-Delay Neuron System and Feistel Network \cite{novel_feedback_block_cipher}}
This paper proposes a feedback block chaotic cipher algorithm (FBCCA) that bases itself on the chaotic time-delay neuron system and the feistel network. Because the algorithm will be so random it will be much more complex and difficult to be analyzed or predicted by any attackers. 

The FBCCA belongs to the DES-like iterated cipher, where the ciphertext would be generated by apply a recursive round function to the plaintext. If we consider an r-round feistel cipher with a block size of $2n$ then the round function being applied to the plaintext can be defined as:
\begin{equation}
Round_i = L_{i-1} || R_{i-1} \rightarrow R_t || F(Z_t, R_{i-1}) \oplus L_{t-1}
\end{equation}
for $i = [1, 2, \ldots r]$, where $L_i$ and $R_i$ are two halves of the block with size of $n$ bits. Thus the output ciphertext block corresponding to the current input plaintext block is fed back into the generation process of the number of round in order to create the ciphertext. Also, the round numbers and the sequence numbers of the S-box (used in each round) have a close relationship with the secret key. Both are also dynamically generated by the chaotic system and can be used to calculate the secret key by the following equation:
\begin{equation}
R_k = 16 + floor(X^*_N \cdot 16)
\end{equation}
Then in order to decrypt the ciphertext, the round operations can be applied Rk times to the right and left part of the ciphertext block ($L_i$ and $R_i$) in order to retrieve the plaintext once again.

The FBCCA is tested via computer simulation using MATLAB 6.1 on a portable PC with P4-M 2.0GHz CPU and 256MB RAM. They used two different plaintext messages, with only one letter difference, and two different secret keys, also with only one letter difference, in order to test whether the algorithm works as well as to test the sensitivity of the algorithm with the letter differences being so small. The results of the test show that each time the ciphertext is completely different for each cipher even with the small letter differences and that without using the exact secret key in decryption, the result plaintext does not match the original message correctly. Thus, the probability of successfully decrypting FBCCA by using a brute-force attack is very small.

\section{Proposed Implementation}
Our proposed design consists of a combination of an interconnection network and the Vigen\`{e}re cipher. The users input will pass through the Vigen\`{e}re cipher before being fed through the interconnection network. This combination implements two methods commonly used in text ciphers: character substitution and transposition. We will start with a brief overview of the system layout then go into detail on each integral part of the cipher implementation.

\subsection{Overview}
Our proposed block cipher contains an interconnection network in the Omega configuration combined with a Vigenere cipher. The input to the system is two 16-byte blocks, one block containing the key and one block containing the data to be encrypted. This is why our implementation is a block cipher. Every block of data to be encrypted must have both the key and data input. Our system does not have any form of memory of previous inputs and does not contain any state machines. It is simply a combinational implementation that creates an output solely dependent on the current inputs. A visual system overview is given in figure \ref{fig:sys_overview}.

\begin{figure}
	\centering
	\includegraphics[width=\columnwidth]{system_overview.pdf}
	\caption{Block diagram of the proposed system}
	\label{fig:sys_overview}
\end{figure}

For encrypting data, the previously mentioned data flow occurs. Data and key are input to the Vigenere cipher and then flow into the interconnection network. To speed up performance, each input on the interconnection network is allocated the necessary hardware to perform the character substitution. This means there are 16 Vigenere blocks, one Vigenere block per input to the ICN. Decryption is exactly the opposite. Data flows into the interconnection network first, but backwards, then goes through the Vigenere cipher block to reverse the character substitution.

\subsection{Interconnection Network}
The interconnection network chosen for our implementation is an Omega network. The configuration consists of three stages of sixteen switchboxes per stage. Each switchbox has two inputs and two outputs, each consisting of eight bits, and a one-bit select line. The inputs and outputs are each eight bits to allow one ASCII character to be fed into each data line. In our configuration this will allow a block of sixteen bytes, or sixteen characters, to be transposed at a time. A sketch of our interconnection layout is given in figure \ref{fig:3x8_omega}. On the left you see sixteen data inputs, each numbered with a unique number from 0-15. This signifies the character position in the sixteen-character block. The same scheme is used for the data outputs. The line at the bottom of each switchbox is the switchbox select line and its purpose will be discussed. It is important to note that each select line is unique in the entire ICN. The input to these select lines is the key that comes with each block of data. You may notice that each key block is 16 bytes and we only see 24 select lines, for a total of 3 bytes for select. To feed the select, a 3-byte subset is chosen from the key. Currently, these three bytes are the three bytes at the lowest address of the block. In our implementation, these are the bytes at indices 0, 1, 2 in the key array. Simply transposing the positions of characters in each block in the same way would not be too difficult to decipher. The pattern would not change and could likely be found through studying the relationship between inputs and outputs. This is why the switchbox select lines change all the time. Having the select lines being driven by the key makes the switchbox configurations dynamic.

\begin{figure}
	\centering
	\includegraphics[width=\columnwidth]{3StageOmega3x8.pdf}
	\caption{Three stage Omega interconnection network}
	\label{fig:3x8_omega}
\end{figure}

Each switchbox has the capability to change how the data inputs are connected to the data outputs. This is controlled by the select line. A value of 0 on a select line connects the first data input to the first data output, and the second data input to the second data output. A value of 1 on the select line switches these connections; the first data input is passed to the second data output and the second data input is connected to the first data output. It simply switches these connections.

The Verilog module for the switchboxes is very simple. It is a purely combinational and simple module that consists of only two lines. To model combinational logic in Verilog we used the \texttt{assign} statement and a ternary operator with a conditional check on the select line. If the select line is high, the second data input is connected to the first data output and the first data input is connected to the second data output. Simply, if select is 1, the connections cross. If select is low, however, the connections are straight through. The portion of the switchbox module that handles this function is shown below.

\begin{lstlisting}
assign data_out1 = (sel) ? data_in2 : data_in1;
assign data_out2 = (sel) ? data_in1 : data_in2;
\end{lstlisting}

The reason for modeling it using asynchronous logic is for speed and simplicity. As mentioned, using this type of coding in HDL allows the synthesis tool to map this functionality to the basic logic gates, such as inverters, ANDs, ORs, and so on. Any time the input changes, the output will change instantaneously. The same functionality could be modeled using synchronous logic with the select line being checked on every rising edge of the clock but this will introduce some delay (a delay at most the clock period, but a delay nonetheless) and will also require more resources on the FPGA. Typically, synchronous logic blocks synthesize into some combinational logic as well as flip-flops. There is no reason to synchronize events at this level and saving resources on the chip is always beneficial so we modeled it asynchronously.

If we zoom out a bit we can look at the all connections between the switchboxes which together form the interconnection network. As mentioned, the ICN handles one block of data (16 characters) at a time. To handle 16 bytes, there must be a data bus of 16 bytes, or 128 bits. Multiple buses of 128 bits are what form these connections. On the input to the interconnection network, there is a 128-bit bus for handling data and a 24-bit bus for handling the key (3 chars for the key). The output of the interconnection network is a single 128-bit bus. As there are three stages in the interconnection network there must also be a data connection between these three stages. To handle this, there are two intermediate data buses, each 128 bits wide, one for between the first and second stages and the other for between the second and third stages.

Connections between these buses and the individual switchboxes are done in the Omega interconnection network Verilog module. Twenty-four switchboxes are instantiated and slices of bits are connected to each port on each switchbox. To give an example of how this is done, let's consider the first switchbox in the first stage, the one you see in the upper left corner of figure \ref{fig:3x8_omega}. Input 0 is connected the switchbox by connecting bits 0-7 of the data input to data input 1 of the switchbox. In Verilog, bit-slicing like this can be done in a manner as shown below. The first two lines show the 128-bit data bus and a temporary 8-bit bus, and the third line shows choosing the first 8 bits from that and storing it in the temporary 8-bit bus.

\begin{lstlisting}
input [127:0] data_in;
wire [7:0] byte_slice;
assign byte_slice = data_in[7:0];
\end{lstlisting}

This manner of bit-slicing is used to make the all the connections between any bus and switchbox and is used very often in HDL coding. The characters on the input bus are mapped sequentially to the switchbox inputs in the first stage. In other words, the first switchbox will get bits 0-7 and 8-15 tied to its first and second data inputs, respectively. This manner is continued down the entire input bus. The intermediate stages, however, work a bit differently. Let's consider the first intermediate stage, between the first and second stages in the interconnection network. This bus is driven by the previous stage's outputs, and again is driven sequentially. Then, the connections on the next stage's inputs are made according to the layout of a 3-stage Omega network. To make another example, we'll again consider the first switchbox in the first stage. The first output would drive bits 0-7 of the first intermediate 128-bit bus and the second output would drive bits 8-15 of the same bus. The inputs of the next stage, however, would pull from the proper location on the bus according to the interconnection network layout. The first switchbox in the second stage, in the top center of the diagram, would have both inputs tied to bits 0-7 and 64-71, respectively. This is repeated for the outputs on this stage, and the inputs on the next stage. Finally, the outputs are tied to the output bus sequentially as they are on the input bus. An example of some sample texts that were run through a behavioral simulation of our interconnection network is given in table \ref{tab:icn_sample}.

\begin{table}
	\begin{tabular}{lll}
		\textbf{Input} & \textbf{Select} & \textbf{Output}\\
		\hline\\
		ABCDEFGHIJKLMNOP & 000 & AEIMBFJNCGKODHLP\\
		ABCDEFGHIJKLMNOP & ”ABC” & AENIJFBMDPKGCHOL\\
		KLMNOPQRSTUVWXYZ & ”ZYX” & KWOTSPXLRNUYZVMQ\\
		HELLO BIG KITTY! & ”HEL” & HOT GTE BLIYL!KI\\\\
	\end{tabular}
	\caption{Sample texts run through a 3-stage Omega ICN}
	\label{tab:icn_sample}		
\end{table}

\subsection{Vigenere Cipher}
The heart of a Vigenere cipher is a data structure typically called the Vigenere square. This is essentially just a 2-dimensional array of characters, with one row and column per character that can be input to the cipher. See figure \ref{tab:vig_square} for an example of a small Vigenere square that only allows encoding of characters from ``A'' to ``Z''. In our case, we allow all printable ASCII characters in the ASCII range of $[32 \rightarrow 126]_{10}$. This includes all printable characters except for line feeds and carriage returns. Essentially it is all characters on an American qwerty keyboard except for returns, starting with \texttt{space} and ending with \texttt{\~}. Each row of the Vigenere square contains the same data as every other row, but shifted by a different amount, called the \emph{shamt}, with the carryout rolled around. The \emph{shamt} in the first row is 0, the \emph{shamt} in the second row is 1, the third row is 2, and so forth. To find the character to substitute your input character with, you would find the row corresponding to your input character, find the column corresponding to your key character, then select the character in the square where these two intersect. For example, an input character of `A' and a key character of `f' would require you to index the array at [A][f], or [65][102]. Because, however, we are not using all characters in the standard ASCII encoding, the indices are offset by 32. To normalize our indices, we subtract 32 from each index. Using the previous key and input character, the new array index would be [33][70].

\begin{table}
	\centering
	\includegraphics[width=\columnwidth]{vig_square.pdf}
	\caption{Vigenere square for input characters `A' to `Z'}
	\label{tab:vig_square}
\end{table}

The easiest way to model the Vigenere square would be to build a 2-dimensional array and index the array as shown above. This implementation would take up 676~B of memory. Our implementation, however, covers much more characters than `A' to `Z', and would thus require 95\textsuperscript{2} bytes, or 9025~B of memory. This is a significant amount. It was noticed that since every row contains the same data, just shifted a different amount, this 2-dimensional array could be emulated using a single row. If our input character and key characters are $A$ and $B$ respectively and we handle a total of 95 different characters, the index into the new array would be 
\begin{equation}
(A + B) \bmod 95
\label{eqn:rom_index_calc}
\end{equation}
Using this method and a single dimension array allows great savings in memory as it only requires 95~B of memory.

This data is stored in a 95x8 bit of ROM in the custom Verilog ROM module. As this data will only be read, it was suitable to store it in a ROM as opposed to a RAM. There are multiple ways to have your data synthesized into memory during HDL synthesis as well as instantiable IP cores available through the Xilinx ISE tool suite. IP cores require substantial resources on the chip and provide benefits that would not benefit our use, such as synchronization with the clock. We implemented the ROM using a switch statement in which the conditional is the decimal value of the character minus 32 (to normalize the index). The output is updated any time the input changes, providing an asynchronous ROM.

The ROM has a single 8-bit input and a single 8-bit output. The input is the index into the ROM and the output is the resulting substitute character. The index is computed as show in equation \ref{eqn:rom_index_calc} where $A$ is the ASCII value of the input character minus 32 and $B$ is the ASCII value of the key character minus 32. The output is an ASCII character, which is then tied to one input on the interconnection network.

The Vigenere block does have a synchronous element to it simply due to the arithmetic that is performed when calculating the new index into the one-dimension Vigenere square. This does take a small amount of time so the assignment from the result of this arithmetic operation to the address of the ROM occurs at every rising edge of the clock. In our system, the clock runs at a frequency of 100~MHz.

\subsection{System Interface}
With this cipher system running on an FPGA and not on the CPU in a computer, there was need for some way to send data to the cryptosystem and receive the data from it. Inspiration for the physical communication medium came from the PC-FPGA interface used in the Computer System Design lab taught here on campus at USF. In a few of the labs the students are required to communicate with the FPGA through a terminal on the PC and this is made possible over a serial cable connected to the RS-232 port on the PC and the RS232 port on the Xilinx XUPV5-LX110T Virtex-5 Evaluation Platform. UART communication on the FPGA side is handled by UART modules developed for the Virtex-5 and provided by Xilinx for use with their PicoBlaze 8-bit softcore microcontroller. These UART modules provide a way to extract bytes at a time from their internal 16-byte buffer and send bytes at a time the same way.

The PC interface is provided by a custom Python script. This script handles formatting the inputs, sending the inputs to the FPGA, and receiving the outputs. The text to be encoded is loaded from a file and the key is input by a user through the terminal. As the blocks are 16 bytes in size, the plaintext to be encoded is broken up into 16-byte blocks. If the plaintext length is not a factor of 16, the `=' character is appended to the original plaintext until the length is a factor of 16 and this becomes the new plaintext. The key length can be any size. If the key length equals the plaintext length, the key is unmodified. If the key length is less than the plaintext length, the key is repeated along the plaintext until the key length matches the plaintext length. If the key length is more than the plaintext length, the characters after the length of the plaintext are ignored. The script then transmits one 16-byte block of plaintext and one 16-byte block of the key and receives one 16-byte block of response, then writes this response to a file. This process continues until all of the plaintext has been transmitted.

Since the UART modules used as an interface for the FPGA only provide a single byte at a time, an internal counter is used to pull the 32 bytes (16-byte key, 16-byte plaintext) from the UART receiver. The first 16 bytes are known to be the key and the following 16 bytes are known to be the plaintext so these signals are connected appropriately internally. On the next falling clock edge after all 32 bytes have been received, the output of the ICN is captured into a temporary variable and transmission of these 16 bytes initiates. While this transmission is occurring the system allows new data to be received over the serial port. This method allows more throughput than if the system blocked receiving while it was transmitting. Since the UART buffers are only 16 bytes, any new data received after the buffer filled would result in data loss.

\subsection{Decryption}
Any encryption scheme is worthless if the encrypted data cannot be recovered, so our implementation also has a method for decryption. In essence, to decrypt the data flows in the reverse direction through the interconnection network. The key remains the same for decryption as encryption, classifying this as a symmetric cryptosystem. A slightly different approach is taken for reversing the Vigenere cipher, however. The equation shown below is used to reverse the substitution cipher, with $A$ being the ASCII value of the ciphertext and $B$ being the ASCII value of the key.
\begin{equation}
|(A - B)| \bmod 95
\label{eqn:dec_rom_index_calc}
\end{equation}

A hardware DIP switch on the Xilinx evaluation board is used to select which output to send over the UART: encryption output or decryption output. Simply moving this switch toggles the function. The Python interface program asks the user whether they would like to encrypt or decrypt. The only change in the Python program is the names of the input and output files.

\section{Evaluation}
The evaluation of our proposed method was conducted using a Xilinx Virtex-5 XC5V-LX110T FPGA board. This was connected to an Dell OptiPlex 7010 with an Intel Core i7-3770 processor and 16~GB of memory via the RS-232 serial port. The communication protocol utilized for our evaluation was UART because this was the most familiar to us with resources for this protocol already available on hand. Also, our choice in the type of FPGA board used for our evaluation was also chosen due to its ease of access in our graduate computer labs and added no cost for us to utilize during our evaluation. The same could be said about our choice to use the model of Dell OptiPlex desktop which was also readily available to us in our university lab.

Our evaluation consisted of 3 test cases that were evaluated among several different keys. We started with a simple single character and four character key and then submitted more complex keys to provide a wider scope to our evaluation. The test cases consisted of Harvard sentences chosen at random amongst a various list of Harvard sentences via the web. Our reasoning for selected Harvard sentences specifically amongst various other test phrases we could have used for our test cases is that Harvard sentences offer a more uniformly balanced choice of words that consist of phonetically balanced choice of characters of the alphabet. To us, this would illustrate a very balanced test case that would remove some of the bias attributes that could accompany various other test phrases whether chosen intentionally by us thinking up phrases or unintentionally by having fellow peers choose phrases for us at random.

For our final test case we chose a random USA Today article \cite{usa_today_article} via the web that we felt would offer an extended length of text that would be used to benchmark not only the efficiency of the encryption, but also the performance of the encryption as well. The article contains 4,454 ASCII characters including spaces which we felt signified a strong test case to measure both efficiency and performance for encrypting and decrypting the article.

For the first test case, consisting of a single Harvard sentence, we ran three different key cases. The first key case consisted of just a single character key, the second key case consisted of a four character key and the final key case consisted of a single Harvard sentence chosen at random from a list of various Harvard sentence but was not the same Harvard sentence used for the first test case. These three different key cases offer a balanced scope for testing our encryption and decryption schemes from a simplistic single character case to a more complex entire collection of characters in the form of a sentence case. Table \ref{tab:three_keys_one_text} contains our first test case with the three results from the three key cases applied to the test case.

\subsection{Test Case 1}
Test case 1 consisted of 36 characters with spaces. The cipher has to group the input string of characters into blocks of 16 because the ICN has 16 inputs and 16 outputs. The ICN must receive exactly 16 inputs from each cipher block so if a string does not have an equal multiple of 16 number of a characters then as stated in our proposed method, the string will be concatenated with equal signs to make the string equal to a multiple of 16. Looking further at test case 1 being only 36 characters the cipher had to concatenate 12 equal signs to the end of the test case string in order to reach 48 (a multiple of 16). However, looking at the results for each key case you would never know that equal signs were concatenated at the end of test case 1’s string because the results to do not show a consistent repetition of 12 characters at the end of their string. This is because the Vigenere cipher’s offset is dynamic at each character that is encrypted in the string which further offers even more complexity to anyone trying to decrypt the resulting string by brute force.

\begin{table}
	\begin{tabular}{l p{\columnwidth}}
		Test case 1: & \hbox{
		\begin{lstlisting}
The boy was ther
e when the sun r
ose.
		\end{lstlisting}}\\
		
		Single character key case: & \hbox{
		\begin{lstlisting}
=~#Q*s1+22U=--fG
aaD6aTVYQJCGU[JG
VUGGJTWJPaGaaaPY
		\end{lstlisting}}\\
		
		Four character key case: & \hbox{
		\begin{lstlisting}
~~~Qo~~~~V~~~~~I
dY6dDWVdRKDIW]KI
XJGMGWWYQbHcccQ[
		\end{lstlisting}}\\
		
		Harvard sentence key case: & \hbox{
		\begin{lstlisting}
"~1r~"~" s !!! X
GweTobYsZLgcoWhG
iR]Us`eIWnTlk P&
		\end{lstlisting}}
		
	\end{tabular}
	\caption{Test case 1: Three different keys applied to a single plaintext input}
	\label{tab:three_keys_one_text}
\end{table}

\subsection{Test Case 2}
Moving on to test case 2, which consisted of 10 Harvard sentences separated by a single space between each sentence for a total of 408 characters including spaces. Once again, because this total number of characters is not equal to a multiple of 16, 8 additional equal signs are concatenated to the end of this submitted test case to bring the total number of characters to 416 which is a multiple of 16. For this test case we were able to increase the complexity of the key even more because of the string size by offering a fourth key case that consisted of 10 Harvard sentences chosen at random and that were not contained in the test case itself. We also still evaluated test case 2 with the same three key cases as performed in test case 1. The results for the second test case we performed using our hardware based cipher can be found in table \ref{tab:test_case_2_output} in the appendix.

One thing to note visually from looking at these 4 different key cases that are performed on test case 2 is that the variation on the types of characters used in the cipher increases as the complexity of the key increases which is observation that is to be expected with ciphers of all types. Although there is point were the complexity of the key does not affect the encrypted output as much as it would with a key that only contains one character in it. Focusing on key cases utilizing one Harvard sentence as a key versus ten Harvard sentences as a key it is more difficult to clearly see the level of variation in the characters generated by the cipher. It’s possible with more advanced analysis that a variation in the characters resulting from the Vigenere cipher run could be detected, however, this variation is not going to be as considerable as going from using a single character key to a Harvard sentence key.

Our third and final test case consisted of choosing a random USA Today article online and running the article through our ICN based Vigenere cipher. The whitespace and newline returns were removed from the article before being ran through our cipher because the implementation of our ICN based Vigenere cipher does not account for whitespace and newline returns that are not composed of single space characters. Instead of a newline return a single space is used to separate new paragraphs of the article. The article contains a total of 4,454 characters including spaces which is not a multiple of 16, so 26 equal signs are concatenated to the end of the article string in order for the submitted string to have a multiple of 16 number of characters. The article was submitted with five different key cases, with each key case increasing in complexity and character variation. The key cases consisted of a single character, four character and single Harvard sentence key case as well as a 10 Harvard sentence key case and a USA Today article key case that was not the same article used in the test case itself. The results of these five key cases are conclusive to the fact that the increasing complexity of the key is directly proportional to the variation in characters chosen for the cipher’s resulting output. Further, these results are also conclusive to the fact that all ciphers will increase in variation and complexity as their key used is increased in variation and complexity.

From these results our ICN based cipher performs as it should and producing results conclusive to what a cipher is expected to produce from an encryption scheme. Further, after testing for consistency amongst our test cases we also want to note the level performance achieved from these test cases. When considering performance its an obvious choice for us to consider the latency timings achieved for each 16 block of characters evaluated by our ICN based cipher. Table \ref{tab:latencies_test_case_2} in the appendix are the latency timings for our test case 2 which consisted of 10 Harvard sentences or 416 characters including spaces and 8 concatenated equal signs to the end of the string. The key case used was 10 Harvard sentences that were not the same sentences used in the test case string.

To manually calculate latency we must consider the baud rate used for the communication. The baud rate that our evaluation FPGA board was set to operate at is 9600 bits per second. Next, we must look at how many bits are in one 16 character block. Considering we have 128 bits for text, 128 bits for the key and 128 bits for the result we can conclude that each 16 character block consists of 384 bits. With each character block consisting of no more or less than 384 bits we are able to calculate the latency that we should expect from each character block as
\begin{equation}
384 \textrm{ bits} \div 9600 \textrm{ bits}/\textrm{second} = 0.040 \textrm{ seconds}
\end{equation}
to process each 16 character block through our ICN based Vigenere cipher. However, 40~ms seconds is actually considerably higher than the average latency it took to process test case 2 with key case 2 through our cipher. This is confusing because this means the actual average operating latency is faster than what is to be the expected calculated latency based on the baud rate that we set for the evaluation FPGA board. Further testing would have to be done on the FPGA board itself, starting with connecting a logic analyzer to the serial port of the board to capture the actual timings coming across the serial port from the FPGA board. An oscilloscope is also another option to capture timings but not as user friendly or accurate as a logic analyzer for capturing latency timings.

Lastly, we evaluated the decryption method of our cipher scheme to make sure that we were obtaining consistent data recollection after our cipher encrypted the data. All 3 test cases along with all of the key case results concluded 100\% data recollection without any data loss or failure in successfully decrypting the data results. This further concludes that our ICN based Vigenere cipher is performing consistently across both our encryption and decryption schemes as well performing consistently with all ciphers by offering increasing character variation in our encryption results as the key used for the encryption increases in complexity and variation as well.

\section{Conclusions and Future Work}
Our findings from the evaluation conclude that our proposed method does provide a level of encryption using interconnection networks. We can conclude that we have a fully functional encryption and decryption method that utilizes an ICN based Vigenere cipher. From our evaluation we can also conclude that through stress testing the encryption method using various keys that offer various complexity our results show consistency with increasing the key complexity and variation of characters used we also increase the resulting encryption with greater complexity and variation. Also, the performance measured for our cipher concludes that with a set baud rate an acceptable average latency for each block of data processed by our cipher produced acceptable latency timings. Although, the latency timings actually produced were notably less that what we expect the latency to be through our calculations we still consider these timings acceptable from a performance standpoint.

We have successfully designed a ICN based cipher using a Vigenere cipher encryption scheme, implemented our design into a Xilinx Virtex-5 FPGA board using Xilinx ISE Design Suite version 13.4 to program the board using Verilog, and produced acceptable results from our test cases used for the verification of our design. The variation and complexity of our results are consistent for what is to be acceptable results for a cipher implementation and our latency performance timings are acceptable for what is to be expected for this type of hardware implementation.

In reviewing related works, we can conclude that our proof of concept is very unique in providing an interconnection based encryption scheme using a cipher we were not able to find much work that has been dedicated to this area of research. Furthermore, we can conclude that due to the considerable lack of research touched in this area we can also state that our proof of concept is also a novel concept as well. Based on these findings thus far we find this very encouraging throughout the continuation of this research as well as for any possible future research that this topic can help expand upon.

\printbibliography

\newpage
\appendix
\begin{table}[ht]
\centering
	\begin{tabular}{p{.3\columnwidth} p{\columnwidth}}
		Single character\newline key case: & \hbox{
		\begin{lstlisting}
0q`VK1&$=QKN#`#aECD6aaPJKJaGETQG
aaaUFQUVQNJQGPOKM)NVRaNUCJoGaPWa
GQUVaGaVJJaJVGVGNDMaTICWaFGMaDEC
+aFTP[GVoQhUUaCWNGVaaRaaGVVGJNFQ
aNHVQJoYaJG6NCaaUEFGaMJaCUCEa[KG
KaGGNGTUIPaTCaCa4aJaUQKKoFEaGaUK
TaaHPTKXUVGaFGPGYaaQFa6NDWUGoQJP
HOGLEaQaaWNUGQPKKRUOGJWPaCGEaHPM
QCGoJJUZaaaVYDa6UaaTPaVKDQFGGGJY
VMGRMJoTFCW6EaaTYaIGQaHGUaTFGaGJ
aPRERFaEGJQPTFCQGQDaTJWoCIaa(ITC
aCaQUYFUQWVaGH[TGUHQaaoFCTa#WEaM
KKGNIVP\aCGUaUaTaJPQKaCKIEUFaUTM
		\end{lstlisting}}\\
	
		Four character\newline key case: & \hbox{
		\begin{lstlisting}
o~GVU~~~NR~~~N~cFJ6dDdPHLKbIGVRI
dVUIaTUdROKSIRPM,UVUNdNPDKpIcRXc
TVVdUJaJKKbLXIWIGWaWMLCQbGHOcFFE
dVTSF^G.pRiWWcDYJaadVUaQHWWILPGS
QYVTHModbKH8PEbcHaGdFPJXDVDGc]LI
dUGQGJTNJQbVEcDcdKaXJTK7pGFcIcVM
dXHSaWKWVWHcHIQIdNQIad6\EXVIqSKR
RaLHGdQKbXOWISQMUPOJUMWNbDHGcJQO
FZoMGMUTbbbX[Fb8dKTSadVXERGIIIK[
PTRPGMoYGDX8GcbVdGGTIdH\VbUHIcHL
SEEURIadHKRRVHDSToaWDMWJDJbc*KUE
FUQXa\FdRXWcIJ\VXFQdHdoJDUb%YGbO
N\NLGYPNbDHWcWbVMKQNPdCdJFVHcWUO
		\end{lstlisting}}\\
	
		Harvard sentence\newline key case: & \hbox{
		\begin{lstlisting}
"~6XG"~rOo !!P rGhGTooSWZLW\iuoG
g^Yc ]pcX[W\QnOwlPtG2dbswT]is^Ko
IY YnVW]JU heZ`SZhsb]KlbkJd$WU.F
hn-h^YVe]o{}W Ri[aXsZa.oet6ShI\e
#tLehcNg=ReaPdcn`dJqk[*mn[sVQUiO
OerIZ`oX sWTV]E YR d1R]m|WE.RbkY
lSdJ rri]YVoJYcZhas^Ho6[`$_SU.b0
 cfc_ciXoe`XeTTi_RUZJIanOJVWitn[
hWKsg\sbjwbdd ATe^cr koUTcHbRNIY
4[pX\S#r>WVTu nfLetOUpJgdnVstGNT
I0pm cdSGR^^!QTcLoJrXhY.gttU6MTR
snbQSwU]AeS[a(fW[sc PQ#XgUeAZocO
PXKzec[fsp#ce]mrGi\_t\^]dcssuWLO
		\end{lstlisting}}\\
	
		10 Harvard\newline sentence key case: & \hbox{
		\begin{lstlisting}
="D=O"3='0\11-#KnW P6_UVW` MTToK
dI \ d]hQURoKn\iyl]\-sdsOhbZh\Et
Ydg]w[^KWZ ]Vt\KjW b\klDoNMZeQIQ
sgrP_ey^ `g\Vl<W nnYiReNWehlYY\e
Zdgv_[ aT\TolPet. EU\dWYwbHYU6ie
U[eGdZsP^ rea[QfUs.9 YiOsGGhZrHO
tPuriPRfZ Lhd_T]  dfiIs[eWYKreQd
ByRWgbMVskeR z^OReRWcmnZMVYiwZnT
ed*$YNY^.trtwDrHi rlfTagKZeU[Ghk
rRMEhQ"hbJjJVhsXla oGYeKcneIKlKM
pFWeeP[ecUoNgWaouXewXLd<MM nofFF
 b\m odiJb^nZH[TeSsoei"Y/`[GhaH[
QZPROk)TsTebRdifinb^oOtFW`cKoir\
		\end{lstlisting}}
	\end{tabular}
	\caption{Test Case 2 Output}
	\label{tab:test_case_2_output}
\end{table}

\begin{table}[ht]
\centering
	\begin{tabular}{ll}
		16 Character Block 1 & 0.0409998893738 s\\
		16 Character Block 2 & 0.0369999408722 s\\
		16 Character Block 3 & 0.0370001792908 s\\
		16 Character Block 4 & 0.0360000133514 s\\
		16 Character Block 5 & 0.0369999408722 s\\
		16 Character Block 6 & 0.0360000133514 s\\
		16 Character Block 7 & 0.0369999408722 s\\
		16 Character Block 8 & 0.0369999408722 s\\
		16 Character Block 9 & 0.0370001792908 s\\
		16 Character Block 10 & 0.0360000133514 s\\
		16 Character Block 11 & 0.0369999408722 s\\
		16 Character Block 12 & 0.0360000133514 s\\
		16 Character Block 13 & 0.0379998683929 s\\
		16 Character Block 14 & 0.0399999618530 s\\
		16 Character Block 15 & 0.0390000343323 s\\
		16 Character Block 16 & 0.0390000343323 s\\
		16 Character Block 17 & 0.0390000343323 s\\
		16 Character Block 18 & 0.0380001068115 s\\
		16 Character Block 19 & 0.0399999618530 s\\
		16 Character Block 20 & 0.0379998683929 s\\
		16 Character Block 21 & 0.0390000343323 s\\
		16 Character Block 22 & 0.0380001068115 s\\
		16 Character Block 23 & 0.0390000343323 s\\
		16 Character Block 24 & 0.0389997959137 s\\
		16 Character Block 25 & 0.0380001068115 s\\
		16 Character Block 26 & 0.0390000343323 s\\
		\\
		Average Latency & 0.0379615380214 s
	\end{tabular}
	\caption{Latencies for Test Case 2 Key Case 2}
	\label{tab:latencies_test_case_2}
\end{table}

% if have a single appendix:
%\appendix[Proof of the Zonklar Equations]
% or
%\appendix  % for no appendix heading
% do not use \section anymore after \appendix, only \section*
% is possibly needed

% use appendices with more than one appendix
% then use \section to start each appendix
% you must declare a \section before using any
% \subsection or using \label (\appendices by itself
% starts a section numbered zero.)
%


%\appendices
%\section{Proof of the First Zonklar Equation}
%Appendix one text goes here.

% you can choose not to have a title for an appendix
% if you want by leaving the argument blank
%\section{}
%Appendix two text goes here.


% use section* for acknowledgement
%\section*{Acknowledgment}


%The authors would like to thank...


% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
\ifCLASSOPTIONcaptionsoff
  \newpage
\fi



% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/lio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
%\begin{thebibliography}{1}

%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.

%\end{thebibliography}

% biography section
% 
% If you have an EPS/PDF photo (graphicx package needed) extra braces are
% needed around the contents of the optional argument to biography to prevent
% the LaTeX parser from getting confused when it sees the complicated
% \includegraphics command within an optional argument. (You could create
% your own custom macro containing the \includegraphics command to make things
% simpler here.)
%\begin{biography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{mshell}}]{Michael Shell}
% or if you just want to reserve a space for a photo:

%\begin{IEEEbiography}{Michael Shell}
%Biography text here.
%\end{IEEEbiography}

% if you will not have a photo at all:
%\begin{IEEEbiographynophoto}{John Doe}
%Biography text here.
%\end{IEEEbiographynophoto}

% insert where needed to balance the two columns on the last page with
% biographies
%\newpage

%\begin{IEEEbiographynophoto}{Jane Doe}
%Biography text here.
%\end{IEEEbiographynophoto}

% You can push biographies down or up by placing
% a \vfill before or after them. The appropriate
% use of \vfill depends on what kind of text is
% on the last page and whether or not the columns
% are being equalized.

%\vfill

% Can be used to pull up biographies so that the bottom of the last one
% is flush with the other column.
%\enlargethispage{-5in}

%\printbibliography

% that's all folks
\end{document}


